| Version | Date | Comment |
|---|---|---|
| 0.1 | 2020-11-16 | Started |
| 1.0.92022 | 2022-02-10 | Initial publication. |
| 1.1 | 2024-12-13 | Updates for CC:2022 |
| 2.0 | 2025-01-10Latest draft13 | Draft: Incorporate TRRTs |
|
Assurance
| Grounds for confidence that a TOE meets the SFRs [CC]. |
|
Base Protection Profile (Base-PP)
| Protection Profile used as a basis to build a PP-Configuration. |
|
Collaborative Protection Profile (cPP)
| A Protection Profile developed by international technical communities and approved by multiple schemes. |
|
Common Criteria (CC)
| Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
|
Common Criteria Testing Laboratory
| Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility |
| accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. | |
|
Common Evaluation Methodology (CEM)
| Common Evaluation Methodology for Information Technology Security Evaluation. |
|
Extended Package (EP)
| A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
|
Functional Package (FP)
| A document that collects SFRs for a particular protocol, technology, or functionality. |
|
Operational Environment (OE)
| Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
|
Protection Profile (PP)
| An implementation-independent set of security requirements for a category of products. |
|
Protection Profile Configuration (PP-Configuration)
| A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
|
Protection Profile Module (PP-Module)
| An implementation-independent statement of security needs for a TOE type complementary to one or more Base |
| -PPs. | |
|
Security Assurance Requirement (SAR)
| A requirement to assure the security of the TOE. |
|
Security Functional Requirement (SFR)
| A requirement for security enforcement by the TOE. |
|
Security Target (ST)
| A set of implementation-dependent security requirements for a specific product. |
|
Target of Evaluation (TOE)
| The product under evaluation. |
|
TOE Security Functionality (TSF)
| The security functionality of the product under evaluation. |
|
TOE Summary Specification (TSS)
| A description of how a TOE satisfies the SFRs in an ST. |
|
Administrator
| An Administrator is responsible for management activities, including setting policies that are applied by the enterprise on the platform. An Administrator can act remotely through a management server, from which the platform receives configuration policies and updates. An Administrator can enforce settings on the system that cannot be overridden by non-Administrator users. |
|
American National Standards Institute (ANSI)
| A private organization that oversees development of standards in the United States. |
|
Application
| Software that runs on a platform and performs tasks on behalf of the user or owner of the platform. |
|
Application Programming Interface (API)
| A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform. |
|
Baseboard Management Controller (BMC)
| Or Management Controller. A small computer generally found on Server motherboards that performs management tasks on behalf of an Administrator. |
|
Cipher-based Message Authentication Code (CMAC)
| A mode of AES that provides authentication, but not confidentiality. |
|
Commercial Solutions for Classified (CSfC)
| An US Department of Defense program for delivering cybersecurity solutions that leverage commercial technologies and products. |
|
Credential
| Data that establishes the identity of a user, e.g. a cryptographic key or password. |
|
Critical Security Parameters (CSP)
| Information that is either user or system defined and is used to operate a cryptographic module in processing encryption functions including cryptographic keys and authentication data, such as passwords, the disclosure or modification of which can compromise the security of a cryptographic module or the security of the information protected by the module. |
|
Data-at-Rest (DAR) Protection
| Countermeasures that prevent attackers, even those with physical access, from extracting data from non-volatile storage. Common techniques include data encryption and wiping. |
|
Developer
| An entity that manufactures platform hardware or writes |
| platform software/firmware. For the purposes of this document, vendors and developers are the same. | |
|
Diffie-Hellman Key Exchange (DH)
| A cryptographic key exchange protocol using public/private key pairs. |
|
Distinguished Name (DN)
| Information used in certificate-based operations to uniquely identify a person, organization, or business. |
|
End-User Device (EUD)
| A class of computing platform characterized by having a user interface for a single user. Often, EUDs are portable (e.g., laptop, tablet, mobile device), but this is not necessarily the case (e.g., desktop PC). |
|
General Purpose Operating System
| A class of OS designed to support a wide-variety of workloads consisting of many concurrent applications or services. Typical characteristics for OSes in this class include support for third-party applications, support for multiple users, and security separation between users and their respective resources. |
|
General-Purpose Computing Platform (GPCP)
| A physical computing platform designed to support general-purpose operating systems, virtualization systems, and applications. |
|
Internet of Things (IoT)
| Physical computing devices that are embedded with sensors, processing ability, software, and other technologies that connect and exchange data with other devices and systems over communications networks. |
|
Joint Test Action Group (JTAG)
| A standard for verifying and testing circuit boards after manufacture. |
|
KECCAK Message Authentication Code (KMAC)
| A variable-length keyed hash function described in NIST SP 800-185. |
|
Management Controller (MC)
| Or Baseboard Management Controller (BMC). A small computer generally found on server motherboards that performs management tasks on behalf of an Administrator. |
|
Open Mobile Terminal Platform (OMTP)
| A forum created by mobile network operators to discuss standards with manufacturers of mobile devices. |
|
Operating System (OS)
| Software that manages physical and logical resources and provides services for applications. Operating systems are the generally the primary tenant of a GPCP. |
|
Physical Presence
| A user or administrator having physical access to the TOE. An assertion of physical presence can take the form, for example, of requiring entry of a password at a boot screen, unlocking of a physical lock (e.g., a motherboard jumper), or inserting a USB cable before permitting platform firmware to be updated. |
|
Root of Trust (RoT)
| Roots of trust are highly reliable hardware, firmware, and software components that perform specific, critical security functions. Roots of trust are the foundation for integrity of computing devices. |
|
Sensitive Data
| Sensitive data may include all user or enterprise data or may be specific application data such as PII, emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include credentials and keys. |
|
Subject Alternative Name (SAN)
| An extended X.509 certificate field. |
|
Tenant Software
| Software that runs on and is supported by a platform. In the case of a GPCP, tenant software generally consists of an operating system, virtualization system, or "bare-metal" application. |
|
Trusted Execution Environment (TEE)
| An isolated and secure area that ensures the confidentiality and integrity of code and data loaded inside. |
|
User
| In the context of a GPCP, a User is a human who interacts with the platform through a user interface. Users do not need to be authenticated by the platform to use the platform, but generally authenticate to tenant software such as on Operating System. |
|
Virtualization System (VS)
| A software product that enables multiple independent computing systems to execute on the same physical hardware platform without interference from one other. |
Addresses TRRT 1567 If the GPCP includes Full Drive Encryption (FDE), and the FDE component has been previously evaluated against the FDEcPPs, or will be evaluated against the FDEcPPs concurrently with the GPCP evaluation, then the FDE component may be excluded from the TOE for purposes of the GPCP evaluation.
The requirements associated with some use case encompass those of other use cases. In these situations, a TOE that meets the larger set of requirements meets both use cases. Specifically
This use case adds audit requirements and Administrator authentication requirements to the base mandatory requirements.
For changes to included SFRs, selections, and assignments required for this use case, see G.1 Server-Class Platform, Basic.
This use case adds requirements for audit, physical protections, and Administrator authentication to the base mandatory SFRs. It removes the assumption that the TOE is physically protected by the OE.
For changes to included SFRs, selections, and assignments required for this use case, see G.2 Server-Class Platform, Enhanced.
This use case adds no requirements to the base mandatory SFRs.
For changes to included SFRs, selections, and assignments required for this use case, see G.4 Portable Clients (laptops, tablets), Enhanced.
Although CSfC requires that users maintain physical control of EUDs at all times, this . This use case removes the assumption that the TOE is protected by the OE and adds requirements for audit and basic tamper detection and reportingfor protection of debug ports .
For changes to included SFRs, selections, and assignments required for this use case, see G.5 CSfC EUD.
For changes to included SFRs, selections, and assignments required for this use case, see G.6 Tactical EUD.
This use case adds only audit to the base mandatory SFRs.
For changes to included SFRs, selections, and assignments required for this use case, see G.7 Enterprise Desktop clients.
For changes to included SFRs, selections, and assignments required for this use case, see G.8 IoT Devices.
| Threat, Assumption , or OSP | Security Objectives | Rationale |
| T.PHYSICAL
| O.PHYSICAL_INTEGRITY | The threat T.PHYSICAL is countered by O.PHYSICAL_INTEGRITY as this objective supports detection or prevention of attempts to compromise the physical platform. |
| O.ATTACK_DETECTION_AND_RESPONSE | The threat T.PHYSICAL is countered by O.ATTACK_DETECTION_AND_RESPONSE as this objective supports detection and reporting of attempts to compromise the TOE. | |
| T.SIDE_CHANNEL_LEAKAGE
| O.MITIGATE_FUNDAMENTAL_FLAWS | The threat T.SIDE_CHANNEL_LEAKAGE is countered by O.MITIGATE_FUNDAMENTAL_FLAWS as this objective supports the remedy of critical flaws through update or other technical or operational means. |
| T.PERSISTENCE
| O.PROTECTED_FIRMWARE | The threat T.PERSISTENCE is countered by O.PROTECTED_FIRMWARE as this objective supports maintenance of platform firmware integrity. |
| T.UPDATE_COMPROMISE
| O.UPDATE_INTEGRITY | The threat T.UPDATE_COMPROMISE is countered by O.UPDATE_INTEGRITY as this objective supports ensuring that platform firmware updates are authentic and properly validated prior to installation. |
| O.STRONG_CRYPTOGRAPHY | The threat T.UPDATE_COMPROMISE is countered by O.STRONG_CRYPTOGRAPHY as this objective supports use of proven, standards-based cryptographic mechanisms for ensuring that updates are authentic and maintain their integrity. | |
| O.ATTACK_DETECTION_AND_RESPONSE | The threat T.UPDATE_COMPROMISE is countered by O.ATTACK_DETECTION_AND_RESPONSE as this objective supports detection and reporting of attempts to compromise the TOE. | |
| T.SECURITY_FUNCTIONALITY_FAILURE
| O.SECURITY_FUNCTIONALITY_INTEGRITY | The threat T.SECURITY_FUNCTIONALITY_FAILURE is countered by O.SECURITY_FUNCTIONALITY_INTEGRITY as this objective supports integrity and proper functioning of security functionality. |
| T.TENANT_BASED_ATTACK
| O.TENANT_SECURITY | The threat T.TENANT_BASED_ATTACK is countered by O.TENANT_SECURITY as this objective supports tenant-based security mechanisms to prevent tenant compromise. |
| T.NETWORK_BASED_ATTACK
| O.TRUSTED_CHANNELS | The threat T.NETWORK_BASED_ATTACK is countered by O.TRUSTED_CHANNELS as this provides for integrity and confidentiality of transmitted data. |
| T.UNAUTHORIZED_RECONFIGURATION
| O.CONFIGURATION_INTEGRITY | The threat T.UNAUTHORIZED_RECONFIGURATION is countered by O.CONFIGURATION_INTEGRITY as this provides for integrity of platform configuration. |
| T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR
| O.AUTHORIZED_ADMINISTRATOR | The threat T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR is countered by O.AUTHORIZED_ADMINISTRATOR as this provides for authentication of privileged Administrators. |
| A.PHYSICAL_PROTECTIONA.PHYSICAL_​PROTECTION | OE.PHYSICAL_PROTECTION​PROTECTION | The operational environment objective OE.PHYSICAL_PROTECTION is realized through A.PHYSICAL_PROTECTION. |
| A.ROT_INTEGRITY​INTEGRITY | OE.SUPPLY_CHAIN​CHAIN | The operational environment objective OE.SUPPLY_CHAIN is realized through A.ROT_INTEGRITY. |
| A.TRUSTED_ADMIN​ADMIN | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| A.MFR_ROT​ROT | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| A.TRUSTED_DEVELOPMENT​DEVELOPMENT_AND​AND_BUILD​BUILD_PROCESSES​PROCESSES | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| A.SUPPLY_CHAIN​CHAIN_SECURITY​SECURITY | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| A.CORRECT_INITIAL​INITIAL_CONFIGURATION​CONFIGURATION | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| A.TRUSTED_USERS​USERS | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| A.REGULAR_UPDATES​UPDATES | OE.TRUSTED_ADMIN​ADMIN | The operational environment objective OE.TRUSTED_ADMIN is realized through A.TRUSTED_ADMIN. |
| Requirement | Auditable Events | Additional Audit Record Contents |
|---|---|---|
| FMT_CFG_EXT.1 | ||
| No events specified |
| N/A | |
| FMT_MOF.1 | |
| No events specified |
| N/A | |
| FMT_SMF.1 | |
| No events specified |
| N/A | |
| FMT_SMR.1 | |
| No events specified |
| N/A | |
| FPT_JTA_EXT.1 | |
| No events specified |
| N/A | |
| FPT_PPF_EXT.1 | |
| No events specified |
| N/A | |
| FPT_ROT_EXT.1 | |
| No events specified |
| N/A | |
| FPT_ROT_EXT.2 | |
| [selection: Failure of integrity verification, None] |
| None. | |
| FPT_STM.1 | |
| No events specified |
| N/A | |
| FPT_TUD_EXT.1 | |
| No events specified |
| N/A |
| # | Management Function | Admin | User | Application Notes |
| 1 | Ability to administer the platform [selection: locally, remotely, not at all] |
MMandatory
|
XNot permitted
|
Administration is considered “local” if the Administrator is physically present at the GPCP. Administration is considered “remote” if communications between the Administrator and GPCP is over a network."Not at all" is the proper selection for Function 1 only in the case where the GPCP is incapable of being Administered at all. If "remotely" is selected, then FTP_TRP.1 |
| must be claimed in the ST and |
| Function 5 must be selected.
|
| 2 | Ability to configure and manage the audit functionality and audit data. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FAU_GEN.1 is |
|
claimed in the ST |
|
. |
|||
| 3 | Ability to configure name/address of audit/logging server to which to send audit/logging records. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This function must be claimed if FAU_STG |
|
.1 is |
|
claimed in the ST |
|
. |
|||
| 4 | Ability to review audit records. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FAU_SAR.1 is claimed in |
|
the ST |
|
. |
|||
| 5 | Ability to initiate a trusted channel for remote administration. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FTP_TRP.1 is |
|
claimed in the ST |
|
. |
|||
| 6 | Ability to set parameters for allowable number of authentication failures. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FIA_AFL_EXT.1 is |
|
claimed in the ST |
|
. |
|||
| 7 | Ability to configure password length and complexity. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FIA_PMG_EXT.1 is |
|
claimed in the ST |
|
. If password length and complexity are not configurable, then the Administrator Option should be denied.
|
|||
| 8 | Ability to configure authentication throttling policy. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FIA_TRT_EXT.1 is |
|
claimed in the ST |
|
. If authentication throttling policy is not configurable, then the Administrator Option should be denied.
|
|||
| 9 | Ability to manage authentication methods and change default authorization factors. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FIA_UAU.5 is |
|
claimed in the ST |
|
. If authentication methods are not configurable, then the Administrator Option should be denied.
|
|||
| 10 | Ability to configure of certificate revocation checking methods. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This function must be claimed if FIA_X509_EXT.1 is |
|
claimed in the ST |
|
(i.e., the TOE claims conformance to , version . If TOE does not support configuration of certificate revocation checking methods, then the Administrator option should be denied.
|
|||
| 11 | Ability to configure TSF behavior when certificate revocation status cannot be determined. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This function must be claimed if FIA_X509_EXT.2 is |
|
claimed in the ST |
|
(i.e., the TOE claims conformance to , version . and the claims made in the SFR indicate that the administrator is allowed to configure how the TSF treats a certificate with undetermined revocation status. |
|||
| 12 | Ability to configure default action to take on integrity failure. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FPT_ROT_EXT.2 or FPT_ROT_EXT.3 |
|
are claimed in the ST and "in accordance with Administrator-configurable policy" is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2 |
|
. |
|||
| 13 | Ability to configure default action to take on update failure. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 is |
|
claimed in the ST and "in accordance with Administrator-configurable policy" is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4 |
|
. |
|||
| 14 | Ability to initiate the update process. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if something other than "no mechanism for platform firmware update" is selected in FPT_TUD_EXT.1.1 |
|
. |
|||
| 15 | Ability to determine the action to take on update failure. |
OOptional/Conditional
|
O
|
|
Optional/Conditional
|
This Function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 |
|
are claimed in the ST |
|
. The Administrator Option must be selected if "by express determination of an [Administrator]" is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4 |
| .
The User Option must be selected |
| if "by express determination of an [User]" is selected |
| in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4.
|
|||
| 16 | Ability to determine the action to take on integrity check failure. |
OOptional/Conditional
|
O
|
|
Optional/Conditional
|
This Function must be claimed if FPT_ROT_EXT.2 or FPT_ROT_EXT.3 is |
|
claimed in the ST |
|
. The Administrator Option must be selected if "by express determination of an [Administrator]" is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2 |
| .
The User Option must be selected |
| if "by express determination of an [User]" is selected |
| in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.
|
|||
| 17 | Ability to manage import and export of keys/secrets to and from protected storage. |
OOptional/Conditional
|
X
|
|
Not permitted
|
This Function must be claimed if FCS_STG_EXT.1 is |
|
claimed in the ST |
|
. |
Administration is considered “remote” if communications between the Administrator and GPCP is over a network.
"Not If "not at all" is the proper selection for Function 1 only in the case where the GPCP is incapable of being Administered at allselected in Function 1, then no other management Management Functions may be selected.
The following rationale provides justification for each security objective SFR for the TOE, showing that the SFRs are suitable to meet and achieve the security objectivesaddress the specified threats:
| ObjectiveThreat | Addressed by | Rationale | ||
|---|---|---|---|---|
| T.PHYSICAL | _INTEGRITY
| FPT_JTA_EXT.1 | Supports the objective through Mitigates threat by restricting access to debug ports . | FPT_TUD_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable
| to authorized Administrators or physical presence. | ||||
| FPT_ROT_EXT.3 (objective)Supports the objective through requiring supply chain traceability | Mitigates threat by ensuring integrity of physical components and responding to integrity failures. | |||
| FPT_JTA_EXT.2 (sel-based) | Supports the objective through requiring Mitigates threat by enforcing access control to debug ports to be disabled. | |||
| FPT_PHP.1 (sel-based/objective) | Supports the objective through passive detection of Mitigates threat by passively detecting physical tampering. | |||
| FPT_PHP.2 (sel-based/objective) | Supports the objective through detection and reporting of Mitigates threat by providing methods to detect and report physical tampering. | |||
| FPT_PHP.3 (sel-based) | Supports the objective through resistance to Mitigates threat by resisting physical tampering. | |||
| T.SIDE_​CHANNEL_​LEAKAGE
| FPT_TUD_EXT. | |||
| 1 | Mitigates threat by providing a means to eliminate side-channel flaws through updates. | |||
| T.PERSISTENCE
| FPT_ROT_EXT.1 | Mitigates threat by providing platform integrity to prevent intrusion of a persistent presence on the platform. | ||
| FPT_TUDRVR_EXT.31 (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | FPT_TUDMitigates threat with firmware recovery mechanism in case of failure. | ||
| FCS_STG_EXT.42 (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | O.ATTACK_DETECTION_AND_RESPONSE
| FPT_ROT_EXT.2 | |
| Mitigates threat by enforcing access control on key data to prevent its unauthorized disclosure. | ||||
| T.UPDATE_​COMPROMISE
| FPT_PPF_EXT.1 | Mitigates threat by using the official update process to be the only method to modify platform firmware. | ||
| FPT_STMROT_EXT.1 | Supports the objective by ensuring that audit events are marked with reliable time stamps. | |||
| FAU_GEN.1 (sel-based) | Supports the objective by requiring reporting of security-related audit events. | |||
| FAU_SAR.1 2 | Mitigates threat by providing a means to attest the validity of updates. | |||
| FCS_COP.1/Hash (sel-based) | Supports the objective by requiring that audit events be readable by an Administrator. | FAU_STG.1 Mitigates threat by providing a means to validate the integrity of an update using a hash. | ||
| FCS_COP.1/SigVer (sel-based) | Supports the objective by requiring that audit records be protected from unauthorized deletion. | |||
| FAU_STG.4 (sel-based) | Supports the objective by requiring that audit records be protected from automatic deletion. | |||
| FAU_STG_EXT.1 Mitigates threat by providing a means to validate the integrity of an update using a hash. | ||||
| FPT_TUD_EXT.2 (sel-based) | Supports the objective by requiring that audit records be off-loaded to an external IT entityMitigates threat by using a digital signature mechanism to verify the integrity of updates and a rollback protection mechanism to prevent application of an unauthorized update. | |||
| FPT_PHPTUD_EXT.13 (sel-based) | Supports the objective through passive detection of physical tamperingMitigates threat by using the TOE's root of trust to validate the authenticity and integrity of an update when it is applied. | |||
| FPT_PHPTUD_EXT.34 (sel-based) | Supports the objective through resistance to physical tampering. | O.MITIGATE_FUNDAMENTAL_FLAWS
|
||
| Mitigates threat through an update mechanism that requires physical access to the TOE to use. | ||||
| T.SECURITY_​FUNCTIONALITY_​FAILURE
| FCS_STG_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable. | ||
| (optional) | Mitigates threat by generating keys/secrets and storing them in a secure manner, as well as destroying them on request. | |||
| FCS_CKM.6 (sel-based) | Supports the objective through specifying an authenticated firmware update mechanism. | FPT_TUD_EXT.3 Mitigates threat by using appropriate key destruction methods to protect the confidentiality of credential data. | ||
| FCS_COP.1/SigGen (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | FPT_TUD_EXT.4 Mitigates threat by generating digital signatures with strong encryption. | ||
| FCS_COP.1/SKC (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | |||
| O.PROTECTED_FIRMWARE
| FPT_ROT_EXT.1 | Supports the objective by ensuring that platform integrity is rooted in a trust anchor. | ||
| FPT_PPF_EXT.1 | Supports the objective by requiring that platform firmware be modifiable only through the update process. | |||
| FPT_TUD_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable. | |||
| FPT_ROT_EXT.2 Mitigates threat by establishing strong symmetric-key cryptography. | ||||
| FPT_FLS.1 (sel-based) | Mitigates threat by ensuring a DRBG self-test failure causes the TOE to enter an error state where it cannot perform secure functions using that DRBG. | |||
| FDP_ITC_EXT.1 (sel-based) | Supports the objective by detecting integrity failures in platform firmware. | FPT_RVR_EXTMitigates threat by importing keys and credentials in a secure fashion. | ||
| FCS_RBG.1 (sel-based) | Supports the objective by specifying a means for recovery from a boot firmware failure. | FPT_TUD_EXTMitigates threat by performing random-bit generation with sufficient complexity. | ||
| FCS_RBG.2 (sel-based) | Supports the objective through specifying an authenticated firmware update mechanism. | FPT_TUD_EXTMitigates threat by using an external seed source to ensure sufficiently strong random-bit generation. | ||
| FCS_RBG.3 (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | FPT_TUD_EXTMitigates threat by using an internal seed source to ensure sufficiently strong random-bit generation. | ||
| FCS_RBG.4 (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | |||
| O.UPDATE_INTEGRITY
| FPT_PPF_EXT.1 | Supports the objective by requiring that platform firmware be modifiable only through the update process. | ||
| FPT_ROT_EXT.2 | Supports the objective by validating the integrity of platform firmware prior to execution. | |||
| FPT_TUD_EXT.1 | Supports the objective through requiring that a TOE be either updateable or immutable. | |||
| FPT_TUD_EXT.2 (sel-based) | Supports the objective through specifying an authenticated firmware update mechanism. | |||
| FPT_TUD_EXT.3 (sel-based) | Supports the objective through specifying a firmware update mechanism with delayed authentication. | |||
| FPT_TUD_EXT.4 (sel-based) | Supports the objective through specifying a secure local firmware update mechanism. | O.STRONG_CRYPTOGRAPHY
|
||
| Mitigates threat by using multiple internal seed sources to ensure sufficiently strong random-bit generation. | ||||
| FCS_RBG.5 (sel-based) | Mitigates threat by ensuring that each noise source's random data is combined to ensure strong entropy when multiple sources are used. | |||
| FPT_TST.1 (sel-based) | Mitigates threat by using self-tests to ensure correct operation of the DRBG. | |||
| T.TENANT_​BASED_​ATTACK
| FPT_STM.1 | Mitigates threat by ensuring that audit data indicating a potential attack is accurately timestamped. | ||
| FCS_RBG.6 (optional) | Mitigates threat by providing a well-defined interface by which tenant software can access the TSF to obtain random data. | |||
| FCS_SLT_EXT.1 (optional) | Mitigates threat by using salts to increase the effectiveness of cryptographic functions used to protect against attack. | |||
| FDP_TEE_EXT.1 (optional) | ||||
| Mitigates threat by establishing a trusted execution environment for tenant software to use. | ||||
| FCS_CKM.1/AKAKG (sel-based/optional) | Supports the objective by specifying the requirements for generating asymmetric keysMitigates threat by generating strong cryptographic asymmetric keys to protect stored data. | |||
| FCS_CKM.1/SKSKG (sel-based/optional) | Supports the objective by specifying the requirements for generating symmetric keysMitigates threat by generating strong cryptographic symmetric keys to protect stored data. | |||
| FCS_CKM.26 (sel-based/optional) | Supports the objective by specifying the requirements for cryptographic key establishmentMitigates threat by implementing key destruction to prevent the disclosure of keys used to protect stored data. | |||
| FCS_CKM_EXT.5 (sel-based/optional) | Supports the objective by specifying the requirements for cryptographic key derivationMitigates threat by utilizing strong algorithms to derive keys that protect stored data. | |||
| FCS_COP.1/Hash (sel-based/optional) | Supports the objective by specifying the requirements for cryptographic hashingMitigates threat by implementing hash functions used for trusted communications. | |||
| FCS_COP.1/KATKeyedHash (sel-based/optional) | Supports the objective by specifying the requirements for key agreement and transportMitigates threat by implementing MAC functions used for trusted communications. | |||
| FCS_COP.1/KeyedHashSigGen (sel-based/optional) | Supports the objective by specifying the requirements for keyed hashesMitigates threat by implementing signature generation functions used for protected storage. | |||
| FCS_COP.1/SigGenSigVer (sel-based/optional) | Supports the objective by specifying the requirements for digital signature generationMitigates threat by implementing signature verification functions used for protected storage. | |||
| FCS_COP.1/SigVerSKC (sel-based/optional) | Supports the objective by specifying the requirements for digital signature verification. | FCS_COP.1/SKC Mitigates threat by implementing symmetric encryption functions used for protected storage. | ||
| FAU_GEN.1 (sel-based/optional) | Supports the objective by specifying the requirements for symmetric-key cryptography. | FCS_RBG_EXTMitigates threat by generating audit records that could provide evidence of attack or misuse. | ||
| FAU_SAR.1 (sel-based/optional) | Supports the objective by specifying the requirements for random-bit generation services. | |||
| O.SECURITY_FUNCTIONALITY_INTEGRITY
| FPT_PPF_EXT.1 | Supports the objective by requiring that platform firmware be modifiable only through the update process. | ||
| FCS_STG_EXT.1 (optional) | Supports the objective by specifying the types of credential storage supported by the TOE. | |||
| FCS_CKM.4 Mitigates threat by recording audit data in a manner that could be interpreted to discover evidence of attack. | ||||
| FAU_STG.1 (sel-based) | Mitigates threat by using an external server to preserve audit data that may provide evidence of an attack. | |||
| FAU_STG.2 (sel-based) | Mitigates threat by preventing audit records indicating a potential attack from being destroyed. | |||
| FAU_STG.5 (sel-based) | Supports the objective by specifying the requirements for credential and key destructionMitigates threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated. | |||
| FCS_CKMSTG_EXT.42 (sel-based) | Supports the objective by specifying the timing for credential and key destructionMitigates threat by using cryptography to protect the confidentiality of key data from outside access. | |||
| FCS_STG_EXT.23 (sel-based) | Supports the objective by specifying the types of material that must be encrypted for storageMitigates threat by using cryptography to protect the integrity of key data from outside modification. | |||
| T.NETWORK_​BASED_​ATTACK
| FPT_STM.1 | Mitigates threat by ensuring that audit data indicating a potential attack is accurately timestamped. | ||
| FCS_STGSLT_EXT.3 (1 (optional) | Mitigates threat by using salts to increase the effectiveness of cryptographic functions used to protect against attack. | |||
| FCS_CKM.1/AKG (sel-based) | Supports the objective by specifying the encryption requirements for credential storage. | FDP_ITC_EXT.1 Mitigates threat by generating strong cryptographic asymmetric keys to protect data in transit. | ||
| FCS_CKM.1/SKG (sel-based) | Supports the objective by specifying the requirements for import of keys and credentials. | |||
| O.TENANT_SECURITY
| FCS_ENT_EXT.1 (optional) | Supports the objective by requiring that the TOE provide entropy to tenant software. | ||
| FCS_STG_EXT.1 (optional) | Supports the objective by specifying the types of credential storage supported by the TOE. | |||
| FDP_TEE_EXT.1 (optional) | Supports the objective by specifying the requirements for a trusted execution environment. | |||
| FCS_STG_EXT.2 Mitigates threat by generating strong cryptographic symmetric keys to protect data in transit. | ||||
| FCS_CKM.2 (sel-based) | Mitigates threat by implementing key establishment to negotiate trusted channels to protect data in transit. | |||
| FCS_CKM.6 (sel-based) | Mitigates threat by implementing key destruction to prevent the compromise of trusted channels. | |||
| FCS_COP.1/Hash (sel-based) | Mitigates threat by implementing hash functions used for trusted communications. | |||
| FCS_COP.1/KAT (sel-based) | Supports the objective by specifying the types of material that must be encrypted for storageMitigates threat by implementing key agreement and transport functions used for trusted communications. | |||
| FCS_STG_EXT.3COP.1/KeyedHash (sel-based) | Supports the objective by specifying the encryption requirements for credential storage. | FDP_ITC_EXT.1 Mitigates threat by implementing MAC functions used for trusted communications. | ||
| FCS_COP.1/SigGen (sel-based) | Supports the objective by specifying the requirements for import of keys and credentials. | O.TRUSTED_CHANNELS
|
||
| Mitigates threat by implementing signature generation functions used for trusted communications. | ||||
| FCS_COP.1/SigVer (sel-based) | ||||
| Mitigates threat by implementing signature verification functions used for trusted communications. | ||||
| FCS_IPSEC_EXTCOP.1/SKC (sel-based) | Supports the objective by specifying requirements for the IPSec protocol. | FIA_X509_Mitigates threat by implementing symmetric encryption functions used for trusted communications. | ||
| FAU_GEN.1 (sel-based) | Mitigates threat by generating audit records that could provide evidence of attack or misuse. | |||
| FCS_HTTPS_EXT.1 (sel-based) | Supports the objective by specifying how X.509 certificate validation is performed. | FIA_X509_EXT.2 Mitigates threat by implementing HTTPS as a means to protect data in transit. | ||
| FCS_IPSEC_EXT.1 (sel-based) | Supports the objective by specifying how X.509 certificate authentication is performed.Mitigates threat by implementing IPsec as a means to protect data in transit. | |||
| FTP_ITC_EXT.1 (sel-based) | Supports the objective by specifying allowable trusted channel Mitigates threat by ensuring that sensitive data in transit uses trusted protocols. | |||
| FTP_ITE_EXT.1 (sel-based) | Supports the objective by specifying requirements for moving data through untrusted channelsMitigates threat by ensuring that sensitive data transmitted over untrusted channels is encrypted prior to transit. | |||
| FTP_ITP_EXT.1 (sel-based) | Supports the objective by allowing physically protected communications channels. | FTP_TRPMitigates threat by using a physically protected channel to protect data in transit. | ||
| FAU_SAR.1 (sel-based) | Supports the objective by specifying allowable uses for trusted channels. | |||
| O.CONFIGURATION_INTEGRITY
| FMT_CFG_EXT.1 | Supports the objective by requiring that default Administrator credentials be changed. | ||
| FIA_UIA_EXTMitigates threat by recording audit data in a manner that could be interpreted to discover evidence of attack. | ||||
| FAU_STG.1 (sel-based) | Supports the objective by requiring Administrators be authenticated before making changes. | FMT_MOF_EXT.1 Mitigates threat by using an external server to preserve audit data that may provide evidence of an attack. | ||
| FAU_STG.2 (sel-based) | Supports the objective by specifying that management functions be performed by Administrators. | FMT_SMF.1 Mitigates threat by preventing audit records indicating a potential attack from being destroyed. | ||
| FAU_STG.5 (sel-based) | Supports the objective by specifying the management functions implemented by the TOE. | FMT_SMRMitigates threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated. | ||
| FTP_TRP.1 (sel-based) | Supports the objective by defining the roles of Administrator and User. | |||
| Mitigates threat by ensuring that remote administration only uses trusted channels. | ||||
| T.UNAUTHORIZED_​RECONFIGURATION
| FMT_CFG_EXT.1 | Supports the objective by requiring that default Administrator credentials be changed. | ||
| FIA_TRT_EXT.1 (optional) | Supports the objective by limiting the number of automated authentication attempts. | |||
| FIA_AFL_EXT.1 (sel-based) | Supports the objective by requiring that Administrators be authenticated. | |||
| Mitigates threat by preventing knowledge of a default credential from being used to access the TSF without authorization. | ||||
| FMT_MOF.1 | Mitigates threat by permitting management functions to be used only by authorized users. | |||
| FMT_SMF.1 | Mitigates threat by specifying the management functions implemented by the TSF. | |||
| FMT_SMR.1 | Mitigates threat by defining the management roles which can be used to grant access to management functions. | |||
| FIA_UIA_EXT.1 (sel-based) | Supports the objective by specifying password complexity requirements. | |||
| FIA_UAU.5 (sel-based) | Supports the objective by specifying supported authentication mechanisms. | |||
| FIA_UAU.7 (sel-based) | Supports the objective by requiring that authentication factor feedback be suppressed. | |||
| FIA_UIAMitigates threat by preventing the TSF from being modified by an unauthenticated subject. | ||||
| T.UNAUTHORIZED_​PLATFORM_​ADMINISTRATOR
| FPT_STM.1 | Mitigates threat by ensuring that time-based authentication throttling or lockout is accurately enforced. | ||
| FIA_TRT_EXT.1 (sel-basedoptional) | Supports the objective by requiring Administrators be authenticated before making changesMitigates threat by throttling authentication to prevent access via brute force. | |||
| FIA_X509AFL_EXT.1 (sel-based) | Supports the objective by specifying how X.509 certificate validation is performed.Mitigates threat by limiting further authentication attempts once a failure threshold of a critical authentication mechanism has been reached. | |||
| FIA_X509PMG_EXT.2 (sel-based) | Supports the objective by specifying how X.509 certificate authentication is performed. | FMT_MOF_EXT.1 (sel-based) | Supports the objective by specifying that management functions be performed by Administrators. | FMT_SMF.1 Mitigates threat by enforcing password complexity requirements to prevent credentials from being easily guessed. |
| FIA_UAU.5 (sel-based) | Supports the objective by specifying the management functions implemented by the TOE. | FMT_SMR.1 Mitigates threat by implementing multiple authentication mechanisms for accessing the TSF. | ||
| FIA_UAU.7 (sel-based) | Supports the objective by defining the roles of Administrator and UserMitigates threat by preventing disclosure of authentication data during authentication attempts. |
| Requirement | Auditable Events | Additional Audit Record Contents |
|---|---|---|
| FCS_CKM_EXT.5 | ||
| No events specified |
| N/A | |
| FCS_ |
| RBG. |
| 6 |
| No events specified |
| N/A | |
| FCS_SLT_EXT.1 | |
| No events specified |
| N/A | |
| FCS_STG_EXT.1 | |
| No events specified |
| N/A | |
| FDP_TEE_EXT.1 | |
| No events specified |
| N/A | |
| FIA_TRT_EXT.1 | |
| Authentication throttling triggered. | None. |
| IdentifierKey type | Input parameters | Key derivation algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|---|
| KDF-CTR | [selection: Direct Generation from a Random Bit Generator as specified in FCS_RBG_EXT.1, Concatenated keys] | KDF in Counter Mode using [selection: CMAC-AES-128, CMAC-AES-192, CMAC-AES-256, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as the PRF | [selection: 128, 192, 256] bits | NIST SP 800-108 sec. 5.1 (KDF in Counter Mode) [selection: ISO/IEC 9797-1:2011 (CMAC), NIST SP 800-38B (CMAC), ISO/IEC 18033-3:2010 (AES), ISO/IEC 9797-2:2011 (HMAC), FIPS PUB 198-1 (HMAC), ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)] |
| KDF-FB | [selection: Direct Generation from a Random Bit Generator as specified in FCS_RBG_EXT.1, Concatenated keys] | KDF in Feedback Mode using [selection: CMAC-AES-128, CMAC-AES-192, CMAC-AES-256, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as the PRF | [selection: 128, 192, 256] bits | NIST SP 800-108 sec 5.2 (KDF in Feedback Mode) [selection: ISO/IEC 9797-1:2011 (CMAC), NIST SP 800-38B (CMAC), ISO/IEC 18033-3:2010 (AES), ISO/IEC 9797-2:2011 (HMAC), FIPS PUB 198-1 (HMAC), ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)] |
| KDF-DPI | [selection: Direct Generation from a Random Bit Generator as specified in FCS_RBG_EXT.1, Concatenated keys] | KDF in Double Pipeline Iteration Mode using [selection: CMAC-AES-128, CMAC-AES-192, CMAC-AES-256, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] as the PRF | [selection: 128, 192, 256]bits | NIST SP 800-108 sec. 5.3 (KDF in n Double Pipeline Iteration Mode) [selection: ISO/IEC 9797-1:2011 (CMAC), NIST SP 800-38B (CMAC), ISO/IEC 18033-3:2010 (AES), ISO/IEC 9797-2:2011 (HMAC), FIPS PUB 198-1 (HMAC), ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)] |
| KDF-XOR | Intermediary keys | [selection: exclusive OR (XOR), SHA-256, SHA-512] | [selection: 128, 192, 256] bits | [selection: ISO/IEC 10118-3:2018 (SHA), FIPS PUB 180-4 (SHA)] |
| KDF-ENC | Two keys | Encryption using [selection: AES-CCM, AES-GCM, AES-CBC, AES-KWP, AES-KW] | [selection: 128, 192, 256] bits | [selection: ISO/IEC 18033-3:2010 (subclause 5.2) (AES), FIPS PUB 197 (AES), ISO/IEC 10116:2017 (clause 7) (CBC), NIST SP 800-38A sec. 6.2 (CBC), ISO/IEC 19772:2009 (clause 8) (CCM), NIST SP 800-38C (CCM), ISO/IEC 19772:2009 (clause 11) (GCM), NIST SP 800-38D (GCM), IEEE Std. 1619-2007 (XTS), NIST SP 800-38E (XTS), ISO/IEC 19772:2009, clause 7 (Key wrap), NIST SP 800-38F sec. 6.2 (KW), NIST SP 800-38F sec. 6.3 (KWP)] |
| KDF-HASH | Shared secret, salt, output length, fixed information | [assignment: Hash function from FCS_COP.1/Hash] | [selection: 128, 192, 256] bits | NIST SP 800-56C rev2, sec. 4 |
| KDF-MAC | Shared secret, salt, IV, output length, fixed information | [assignment: keyed hash from FCS_COP.1/KeyedHash] | [selection: 128, 192, 256] bits | NIST SP 800-56C rev2, sec. 4 |
| KDF-PBKDF | Password, salt, iteration count | [selection: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, HMAC-SHA-512/224, HMAC-SHA-512/256, HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512] | [selection: 128, 192, 256] bits | NIST SP 800-132 |
This requirement ensures that the TOE makes available sufficient entropy to any tenant that requires it. Every entropy source need not provide high-quality entropy, but tenant software must have a means of acquiring sufficient entropy.
| Requirement | Auditable Events | Additional Audit Record Contents |
|---|---|---|
| FPT_ROT_EXT.3 | ||
| Detection of attempted intrusion. | None. |
This PP does not define any Implementation-Based dependent requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
| Requirement | Auditable Events | Additional Audit Record Contents |
|---|---|---|
| FAU_GEN.1 | ||
| No events specified |
| N/A | |
| FAU_STG.1 |
| On failure of logging function, capture record of failure and record upon restart of logging function. | None. |
| FAU_ |
| STG. |
| 2 | |
| No events specified | N/A |
| FAU_STG.5 | |
| No events specified | N/A |
| FCS_CKM.1/ |
| AKG |
| No events specified |
| N/A | |
| FCS_CKM. |
| 1/SKG |
| No events specified |
| N/A | |
| FCS_CKM. |
| 2 |
| No events specified |
| N/A | |
| FCS_CKM |
| . |
| 6 |
| No events specified |
| N/A | |
| FCS_COP.1/Hash | |
| No events specified |
| N/A | |
| FCS_COP.1/ |
| KAT |
| No events specified |
| N/A | |
| FCS_COP.1/ |
| KeyedHash |
| No events specified |
| N/A | |
| FCS_COP.1/ |
| SKC |
| No events specified |
| N/A | |
| FCS_COP.1/ |
| SigGen |
| No events specified |
| N/A | |
| FCS_COP.1/ |
| SigVer |
| No events specified |
| N/A | |
| FCS_HTTPS_EXT.1 | |
| Failure to establish a HTTPS Session. |
|
| Establishment/Termination of a HTTPS session. | Non-TOE endpoint of connection (IP address). |
| FCS_IPSEC_EXT.1 | |
| Failure to establish an IPsec SA. |
|
| Establishment/Termination of an IPsec SA. | Non-TOE endpoint of connection (IP address). |
| FCS_RBG |
| .1 | |
| Failure of the randomization process | None. |
| FCS_RBG.2 | |
| No events specified | N/A |
| FCS_RBG.3 | |
| No events specified | N/A |
| FCS_RBG.4 | |
| No events specified | N/A |
| FCS_RBG.5 | |
| No events specified | N/A |
| FDP_ITC_EXT.1 | |
| No events specified |
| N/A | |
| FIA_AFL_EXT.1 | |
| Failed attempt at Administrator authentication. | None. |
| FIA_PMG_EXT.1 | |
| No events specified |
| N/A | |
| FIA_UAU.5 | |
| No events specified |
| N/A | |
| FIA_UAU.7 | |
| No events specified |
| N/A | |
| FIA_UIA_EXT.1 | |
| All use of the identification and authentication mechanism. | Provided user identity, origin of the attempt (e.g. console, remote IP address). |
| FPT_ |
| FLS.1 |
| Failure |
| of the TSF. |
| None. |
| FPT_JTA_EXT.2 |
| No events specified |
| N/A | |
| FPT_PHP.1 | |
| Detection of intrusion. | None. |
| FPT_PHP.2 | |
| Detection of intrusion. | None. |
| FPT_PHP.3 | |
| Detection of attempted intrusion. | None. |
| FPT_RVR_EXT.1 | |
| No events specified |
| N/A | |
| FPT_TST.1 | |
| Execution of self-tests. | None. |
| FPT_TUD_EXT.2 | |
| [selection: Failure of update authentication/integrity check/rollback, None] |
| Version numbers of the current firmware and of the attempted update. |
| [selection: Failure of update operation, None] |
| Version numbers of the current firmware and of the attempted update. |
| [selection: Success of update operation, None] |
| Version numbers of the new and old firmware images. | |
| FPT_TUD_EXT.3 | |
| [selection: Failure of update authentication/integrity/rollback check, None] |
| Version numbers of the current firmware and of the attempted update. |
| [selection: Failure of update operation, None] |
| Version numbers of the current firmware and of the attempted update. |
| [selection: Success of update operation, None] |
| Version numbers of the new and old firmware images. | |
| FPT_TUD_EXT.4 | |
| No events specified |
| N/A | |
| FTP_ITC_EXT.1 |
| Termination of the trusted channel. | User ID and remote source (IP Address) if feasible. |
| Failures of the trusted |
| path functions. | User ID and remote source (IP Address) if feasible. |
| Initiation of the trusted |
| channel. | User ID and remote source (IP Address) if feasible. |
| FTP_ITE_EXT.1 | |
| No events specified |
| N/A | |
| FTP_ITP_EXT.1 | |
| No events specified |
| N/A | |
| FTP_TRP.1 | |
| Initiation of the trusted channel. | Administrator ID and remote source (IP Address), if feasible. |
| Termination of the trusted channel. | Administrator ID and remote source (IP Address), if feasible. |
| Failures of the trusted path functions. | User ID and remote source (IP Address), if feasible. |
Table 9: Auditable Events for the TLS Functional Package
| FCS_TLSC_EXT.1 | Failure to establish a session. | Reason for failure. |
| FCS_TLSC_EXT.1 | Failure to verify presented identifier. | Presented identifier and reference identifier. |
| FCS_TLSC_EXT.1 | Establishment/termination of a TLS session. | Non-TOE endpoint of connection. |
| FCS_TLSS_EXT.1 | Failure to establish a session. | Reason for failure. |
| FCS_DTLSC_EXT.1 | Failure of the certificate validity check. | Issuer Name and Subject Name of certificate. |
| FCS_DTLSS_EXT.1 | Failure of the certificate validity check. | Issuer Name and Subject Name of certificate. |
The ST Author must select "removable media" if the TOE supports offload of audit data using removable media such as thumb drives or disks.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
| Identifier | Cryptographic key generation algorithm | Cryptographic |
|---|
| algorithm parameters | List of standards | |
|---|---|---|
| RSA | RSA | Modulus of size [selection: 2048 |
| , 3072 |
FIPS PUB 186-4 sec. B.4 [key generation]
FIPS PUB 186-4 sec. B.4 [key generation]
| 5 (Section A.2.2)
[selection: NIST SP 800-186 (Section 3) [NIST Curves], RFC 5639 (Section 3) [Brainpool curves]] |
|||
| FFC-ERB | FFC-ERB - Extra Random Bits | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation]
[selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
| FFC-RS | FFC-RS - Extra Random Bits | Static domain parameters approved for [selection:
| NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation]
[selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]] |
| EdDSA | EdDSA | Domain parameters approved for elliptic curves [selection: Edwards25519, Edwards448] | NIST FIPS PUB 186-5 (Section 6.2.1) [key-pair generation]
NIST SP 800-186 (Section 3.2.3) [Edwards Curves] |
| KCDSA | KCDSA | Domain parameters generation with (L, N) = [selection: (2048, 224), (2048, 256), ( |
| 3072, 256)] |
FIPS PUB 186-4 sec. B.4 [key generation]
| bits | ISO/IEC 14888-3:2018 (Subclause 6.3) [KCDSA] | ||
| EC-KCDSA | EC-KCDSA | Elliptic Curves [selection: P-224, B-233, K-233, P-256, B-283, K-283] | ISO/IEC 14888-3:2018 (Subclause 6.7) [EC-KCDSA]
NIST SP 800-186 (Section 3) [NIST Curves] |
| LMS | LMS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] | RFC 8554 [LMS]
NIST SP 800-208 [parameters] |
| HSS | HSS | Private key size = [selection:
]
Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25] Number of levels = [selection: 1, 2, 3, 4, 5, 6, 7, 8] | RFC 8554 [HSS]
NIST SP 800-208 [parameters] |
| XMSS | XMSS | Private key size = [selection:
]
Tree height = [selection: 10, 16, 20] | RFC 8391 [XMSS]
NIST SP 800-208 [parameters] |
| XMSS(MT) | XMSS(MT) | Private key size = [selection:
]
(Total Tree height, Number of Levels) = [selection: (20, 2), (20, 4), (40, 2), (40, 4), (40, 8), (60, 3), (60, 6), (60, 12)] | RFC 8391 [XMSS(MT)]
NIST SP 800-208 [parameters] |
Also, this SFR must be included in the ST if FCS_IPSEC_EXT.1 is claimed, or if "causing the TOE to generate [asymmetric] keys/secrets" is selected in FCS_STG_EXT.1.2.
If this SFR is included in the ST, then FCS_CKM.
For Curve25519, see also, final draft NIST FIPS PUB 186-5, Oct 2019.
When generating ECC keys pairs for key agreement and if “ECDH” or “ECDH-Ed” is claimed in FCS_CKM_EXT.7, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.
When generating ECC key pairs for digital signature generation and if “ECDSA” or “EC-KCDSA” are claimed in FCS_COP.1/SigGen, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.
When generating EdDSA key pairs for digital signatures and if “EdDSA” is claimed in FCS_COP.1/SigGen, then “EdDSA” must be claimed here. The chosen domain parameters determine the size of the private keys and the public keys.
For LMS, HSS, XMSS, and XMSSMT, the key sizes do not represent the expected security strength. All key sizes given here correspond to an expected security strength of 128 bits, per NIST SP 800-208.
For HSS and XMSSMT the same hash or XOF function must be used at each level. Within each level, the same Winternitz parameter must be used but can be different for each level. For HSS, within each level, the same tree height must be used but can be different for each level.
The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y.
The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:
To test the cryptographic and field prime generation method for the provable primes method or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set.
For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm
This component may also be included in the ST as if optional.
| Identifier | Cryptographic Key Generation Algorithm | Cryptographic Key Sizes | List of standards |
|---|---|---|---|
| RSK | Direct Generation from a Random Bit Generator as specified in FCS_RBG |
| [selection: |
| 123, |
| 256, |
| 512] bits | NIST SP 800-133 |
| Revision 2 |
| (Section 6.1)[Direct generation of symmetric keys] |
This SFR must be included in the ST if "causing the TOE to generate [symmetric] keys/secrets" is selected in FCS_STG_EXT.1.2.
If this SFR is included in the ST, then FCS_CKM.
This component may also be included in the ST as if optional.
In the case of volatile memory, the selection “removal of all references to the key directly followed by a request for garbage collection” is used in a situation where the TSF cannot address the specific physical memory locations holding the data to be erased and therefore relies on addressing logical addresses (which frees the relevant physical addresses holding the old data) and then requesting the platform to ensure that the data in the physical addresses is no longer available for reading (i.e. the “garbage collection” referred to in the SFR text).
The selection for destruction of data in non-volatile memory includes block erase as an option, and this option applies only to flash memory. A block erase does not require a read verify, since the mappings of logical addresses to the erased memory locations are erased as well as the data itself.
Some selections allow assignment of “some value that does not contain any CSP.” This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG
The TOE must have mechanisms to destroy keys and key material in persistent storage using an approved method as specified in FCS_CKM.4. Examples of keys and key material include intermediate keys, encryption keys, signing keys, verification keys, authentication tokens, and submasks.
The TOE will have mechanisms to destroy keys and key material when the keys and key material is no longer needed. Based on their implementations, vendors will explain when certain keys are no longer needed.
The evaluator shall verify that the KMD includes a key lifecycle that includes a description where key materials reside, how the key materials are used, how it is determined that keys and key material are no longer needed, and how the material is destroyed once it is no longer needed. The evaluator shall also verify that all key destruction operations are performed in a manner specified by FCS_CKM.4.
This component may also be included in the ST as if optional.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
The TSF shall perform [keyed hash message authentication] in accordance with a specified cryptographic algorithm [selection: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, KMAC-128, KMAC-256] and cryptographic key sizes [assignment: key size (in bits)] that meet the following: [selection: ISO/IEC 9797-2:2021 sec. 7 (HMAC), ISO/IEC 9797-2:2021 sec. 9 (KMAC), FIPS PUB 198-1 (HMAC), NIST SP 800-185 sec. 4 (KMAC)]. Application Note: This SFR must be included in the ST if it is a service provided by the TOE to tenant software, or if it is used by the TOE itself to support or implement PP-specified security functionality.This SFR must be included in the ST if FCS_IPSEC_EXT.1 is claimed.
Also, this SFR must be claimed under the following conditions:
The HMAC key size falls into a range between L1 and L2 defined in ISO/IEC 10118 for the appropriate hash function (e.g., for SHA-256 L1 = 512, L2 = 256) where L2 ≤ k ≤ L1. Evaluation Activities
This test is derived from The Keyed-Hash Message Authentication Code Validation System (HMACVS), updated 6 May 2016.
The evaluator shall provide 15 sets of messages and keys for each selected hash algorithm and hash length/key size/MAC size combination. The evaluator shall have the TSF generate HMAC or KMAC tags for these sets of test data. The evaluator shall verify that the resulting HMAC or KMAC tags match the results from submitting the same inputs to a known-good implementation of the HMAC or KMAC function, having the same characteristics.
This component may also be included in the ST as if optional.
| Cryptographic algorithm | Cryptographic key size | List of standards |
|---|---|---|
| KAS1 (RSA single-party) | [selection: 2048, 3072, 4096, 6144, 8192] bits | NIST SP 800-56B rev2 sec. 8.2 |
| KAS2 (RSA Two-party) | [selection: 2048, 3072, 4096, 6144, 8192] bits | NIST SP 800-56B rev2 sec. 8.3 |
| KTS-OAEP (RSA) | [selection: 2048, 3072, 4096, 6144, 8192] bits | NIST SP 800-56B rev2 sec. 9 |
| RSAES-PKCS1-v1_5 (RSA) | [selection: 2048, 3072, 4096, 6144, 8192] bits | RFC 8017 sec. 7.2 |
| ECDH-NIST (ECDH with NIST curves) | [selection: 256 (P-256), 384 (P-384), 512 (P-521)] | NIST SP 800-56A rev3 |
| ECDH-BPC (ECDH with Brainpool curves) | [selection: 256 (brainpoolP256r1), 384 (brainpoolP384r1, 512 (brainpoolP512r1)] | RFC 5639 sec. 3 |
| DH (Diffie-Hellman) | [selection: 2048, 3072, 4096, 6144, 8192] bits | NIST SP 800-56A rev3, [selection: ] |
| ECDH-25519 (ECDH with Curve25519) | 256 bits | RFC 7748 |
| ECIES | [selection: 256, 384, 512] bits | [selection: ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2 Part 2, SECG SEC1 sec. 5.1] |
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
This SFR must be included in the ST if FCS_IPSEC_EXT.1 is claimed.
Also, this SFR must be claimed under the following conditions:
The HMAC key size falls into a range between L1 and L2 defined in ISO/IEC 10118 for the appropriate hash function (e.g., for SHA-256 L1 = 512, L2 = 256) where L2 ≤ k ≤ L1.
This component may also be included in the ST as if optional.
| Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|
| RSASSA-PKCS1 | RSASSA-PKCS1-v1_5 using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection: RFC 8017, PKCS #1 v2.2 (sec. 8.2), FIPS PUB 186-4, 5 (sec. 5.54)](RSASSA-PKCS1-v1_5) [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| DSS2 | Digital signature scheme 2 using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796-2 (cl. 9) [Digital signature scheme 2] [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| DSS3 | Digital signature scheme 3 using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796-2 (cl. 10) [Digital signature scheme 3] [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| RSASSA-PSS | RSASSA-PSS using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | RFC 8017, PKCS#1v2.2 sec. 8.1 [RSASSAPSS] [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| ECDSA | ECDSA on [selection: brainpoolP256r1, brainpoolP384r1, brainpoolP512r1, NIST P-256, NIST P-384, NIST P-521] using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection:
|
This component may also be included in the ST as if optional.
| Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|
| RSASSA-PKCS1 | RSASSA-PKCS1-v1_5 using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection: RFC 8017, PKCS #1 v2.2 (sec. 8.2), FIPS PUB 186-45, (sec 5.54)][RSASSA-PKCS1-v1_5] [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| DSS2 | Digital signature scheme 2 using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796-2 (cl. 9) [Digital signature scheme 2] [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| DSS3 | Digital signature scheme 3 using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | ISO/IEC 9796-2, (Clause 10) (Digital signature scheme 3) [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| RSASSA-PSS | RSASSA-PSS using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [RFC 8017, PKCS#1v2.2 (Section 8.1)] (RSASSAPSS) [selection: ISO/IEC 10118-3 (cl. 10, 11) [SHA1/2], FIPS PUB 180-4 (sec. 6) [SHA1/2], FIPS PUB 202 [SHA3]] |
| ECDSA | ECDSA on [selection: brainpoolP256r1, brainpoolP384r1, brainpoolP512r1, NIST P-256, NIST P-384, NIST P-521] using [selection: SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512] | [selection: 2048 bit, 3072 bit] | [selection:
|
This component may also be included in the ST as if optional.
| Identifier | Cryptographic algorithm | Cryptographic key sizes | List of standards |
|---|---|---|---|
| AES-CCM | AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] ISO/IEC 19772 cl. 8, NIST SP 800-38C [CCM] |
| AES-GCM | AES in GCM mode with non-repeating IVs; IV length must be equal to 96 bits; the deterministic IV construction method (SP 800-38D, Section 8.2.1) must be used; the MAC length t must be one of the values [selection: 96, 104, 112, 120, 128] | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] ISO/IEC 19772 cl. 11, NIST SP 800-38D [GCM] |
| AES-CBC | AES in CBC mode with non-repeating and unpredictable IVs | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] ISO/IEC 10116, NIST SP 800-38A [CBC] |
| AES-CTR | AES in counter mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] ISO/IEC 10116, NIST SP 800-38A [CTR] |
| XTS-AES | AES in XTS mode with unique [selection: consecutive non-negative integers starting at an arbitrary non-negative integer, data unit sequence numbers] tweak values | [selection: 256 bits, 512 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] IEEE 1619, NIST SP 800-38E [XTS] |
| AES-KWP | KWP based on AES | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] ISO/IEC 19772 cl. 7 [key wrap] NIST SP 800-38F sec. 6.3 [KWP] |
| AES-KW | KW based on AES | [selection: 128 bits, 192 bits, 256 bits] | ISO/IEC 18033-3, FIPS PUB 197 [AES] ISO/IEC 19772 cl. 7 [key wrap] NIST SP 800-38F, sec. 6.2 (KW) |
If “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1 must be claimed. Applicable claims from the , version are made to support X.509 validation functionality, most notably FIA_XCU_EXT.1 (mandatory requirement defining the TOE's use of certificates), FIA_X509_EXT.1 (X.509 certificate validation) and FIA_X509_EXT.2 (X.509 certificate authentication).
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
NIST SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.
This SFR must be included in the ST if random bits are provided by the TOE to tenant software, or if it is used by the TOE itself to support or implement PP-specified security functionality.
This SFR is also needed if the following SFRs are included in the ST: FCS_IPSEC_EXT.1, FCS_SLT_EXT.1, FCS_CKM.1/Also, this SFR must be claimed if "KDF-CTR," "KDF-FB," or "KDF-DPI" is selected in FCS_CKM_EXT.5.
If "HMAC_DRBG (any)" is selected, then FCS_COP.1/KeyedHash must be claimed.
If "Hash_DRBG (any)" is selected, then FCS_COP.1/Hash must be claimed. If "CTR_DRBG (any)" is selected, then FCS_COP.1/SKC must be claimed.
this requirement, the ST
author selects "TSF noise source" if a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if a seed is formed from a combination of two or more noise sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. It multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source"; "multiple TSF noise sources" is only selected if a single DRBG uses multiple noise sources for its seed. The ST author selects "TSF interface for seeding" if noise source data is generated outside the TOE boundary.
If "TSF noise source" is selected, FCS_RBG.3 must be claimed.
If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.
If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed.
The security strength of the entropy used for seeding depends on the functions for which the TSF uses entropy. The security strength for the various functions is defined in Tables 2 and 3 of NIST SP 800-57A.
This requirement must be included in the ST if the TOE generates keys, signatures, or salts for its own use or for tenant software (FCS_CKM.1/AK, FCS_CKM.1/SK, FCS_COP.1/SigGen, FCS_SLT_EXT.1) or if it provides RNG services for tenant software (FCS_RBG_EXT.1).
In addition to the materials below, documentation shall be produced—and the evaluator shall perform the activities—in accordance with Appendix E - Entropy Documentation and Assessment.
This component must be included in the ST if any of the following SFRs are included:
FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST Author should select whether revocation status is verified using OCSP or CRLs. FIA_X509_EXT.2 requires that certificates are used for IPsec; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for SSH, TLS, and HTTPS and, if implemented, must be validated to contain the corresponding extendedKeyUsage.
OCSP stapling and OCSP multi-stapling support only TLS server certificate validation. If other certificate types are validated, either OCSP or CRL must be claimed. If OCSP is not supported the EKU provision for checking the OCSP Signing purpose is met by default.
Regardless of the selection of TSF or TOE platform, the validation must result in a trusted root CA certificate in a root store managed by the platform.
OCSP responses are signed using either the certificate’s issuer’s CA certificate or an OCSP certificate issued to an OCSP responder delegated by that issuer to sign OCSP responses. A compliant TOE is able to validate OCSP responses in either case, but the OCSP signing extended key usage purpose is only required to be checked in OCSP certificates.
The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST
This SFR must also be included if FIA_X509_EXT.1 is claimed.
If "HTTPS" is selected, then FCS_HTTPS_EXT.1 must be claimed.
If "IPsec" is selected, then FCS_IPSEC_EXT.1 must be claimed.
If "TLS" is selected, then the Functional Package for Transport Layer Security must also be claimed.
If "SSH" is selected, then the Functional Package for Secure Shell (SSH) must also be claimed.
The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.
as if optional.
This component may also be included in the ST as if optional, but may be mandatory in the future.
This component may also be included in the ST as if optional, but may be mandatory in the future.
This component must be included in the ST if any of the following SFRs are included:
This component may also be included in the ST as if optional.
Claims from this package are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed.
If the TSF implements a protocol that requires the validation of a certificate presented by an external entity, FIA_X509_EXT.1 and FIA_X509_EXT.2 must be included in the ST. will be claimed. FIA_TSM_EXT.1 may also be claimed if the TSF implements its own trust store. If the TSF implements a protocol that requires the presentation of any certificates to an external entity, FIA_XCU_EXT.2 will be claimed. FIA_X509_EXT.3 will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.
"No authentication of the remote peer" should be selected only if the TOE is acting as a server in a non-mutual authentication configuration. .
| Functional Class | Functional Components |
|---|---|
| Class: |
| Cryptographic Support (FCS) | FCS_CKM_EXT Cryptographic Key Management
FCS_ |
| HTTPS_EXT HTTPS Protocol
FCS_IPSEC_EXT IPsec Protocol FCS_ |
| SLT_EXT Cryptographic Salt Generation
FCS_STG_EXT Cryptographic Key Storage |
| Class: |
| Identification and Authentication (FIA) | FIA_AFL_EXT Authentication Failure Handling
FIA_PMG_EXT Password Management FIA_TRT_EXT Authentication Throttling FIA_UIA_EXT Administrator Identification and Authentication |
| Class: |
| Protection of the TSF (FPT) | FPT_JTA_EXT Debug Port Access
FPT_PPF_EXT Protection of Platform Firmware FPT_ROT_EXT Platform Integrity FPT_RVR_EXT Platform Firmware Recovery FPT_TUD_EXT Platform Firmware Update |
| Class: Security Management (FMT) | FMT_CFG_EXT Secure by Default
|
| Class: Trusted Path/Channels (FTP) | FTP_ITC_EXT Trusted Channel Communications
FTP_ITE_EXT Encrypted Data Communications FTP_ITP_EXT Physically Protected Channel |
| Class: |
FAU_STG_EXT.1, Off-Loading of Audit Data, specifies how audit data may be transmitted or removed from the TOE, which is not covered by any FCS_STG component.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to:
FAU_GEN.1 Audit Data Generation
| User Data Protection (FDP) | FDP_ITC_EXT Key Import
FDP_TEE_EXT Trusted Execution Environment |
Hierarchical to: No other components.
Dependencies to:
FCS_CKM.4 Cryptographic Key Destruction
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
[FCS_CKM.1 Cryptographic Key Generation or FDP_ITC_EXT.1 Key/Credential Import] |
Hierarchical to: No other components.
Dependencies to:
FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
FCS_HTTPS_EXT.1, HTTPS Protocol, defines requirements for the implementation of the HTTPS protocol.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: |
[FCS_TLSC_EXT.1 TLS Client Protocol, or FCS_TLSC_EXT.2 TLS Client Protocol with Mutual Authentication, or FCS_TLSS_EXT.1 TLS Server Protocol, or FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication] |
FCS_IPSEC_EXT.1, IPsec Protocol, requires that IPsec be implemented as specified manner.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Random Bit Generation |
|
FIA_X509_EXT.1 X.509 Certificate Validation |
FCS_RBG_EXT.1, Random Bit Generation, requires random bit generation to be performed in accordance with selected standards and seeded by an entropy source.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_SLT_EXT.1, Cryptographic Salt Generation, requires the TSF to generate salt values in a specified manner.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_RBG |
| Random Bit Generation |
FCS_STG_EXT.1, Protected Storage, requires the TSF to enforce protected storage for keys and secrets so that they cannot be accessed or destroyed without authorization.
FCS_STG_EXT.2, Key Storage Encryption, requires the TSF to ensure the confidentiality of stored data using a specified method.
FCS_STG_EXT.3, Key Integrity Protection, requires the TSF to ensure the integrity of stored data using a specified method.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_CKM. |
| 6 Timing and Event of Cryptographic Key Destruction |
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Protected Storage |
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_COP.1 Cryptographic Operation |
FDP_ITC_EXT.1, Key/Credential Import, requires the TSF to implement one or more means for importing keys and credentials into the TOE, which are not addressed by the FDP_ITC component.
Hierarchical to: No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_STG_EXT.1 Key Storage Encryption
FTP_ITC_EXT.1 Trusted Channel Communications
FTP_ITE_EXT.1 Encrypted Data Communications
FTP_ITP_EXT.1 Physically Protected Channel
FDP_TEE_EXT.1, Trusted Execution Environment for Tenant Software, requires the TSF to implement a trusted execution environment for the use of tenant software.
Hierarchical to: No other components.
Dependencies to: No dependencies.
FIA_AFL_EXT.1, Authentication Failure Handling, requires the TSF to monitor authorization attempts, including counting and limiting the number of attempts at failed or passed authorizations. This extended component permits considerably more flexibility for dealing with multiple authentication mechanisms than FIA_AFL.
The following actions could be considered for the management functions in FMT:
If FAU_GEN.1 is included in the ST, then the following audit events should be considered:
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_CKM |
| .6 Timing and Event of Cryptographic Key Destruction
FIA_SMF.1 Specification of Management Functions |
FIA_PMG_EXT.1, Password Management, requires the TSF to support passwords with varying composition and length requirements.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No other components. |
FIA_TRT_EXT.1, Authentication Throttling, requires that the TSF enforce a limit on authentication attempts.
The following actions could be considered for the management functions in FMT:
The following should be considered for auditable events if FAU_GEN.1 is included in the ST:
FIA_UIA_EXT.1, Administrator Identification and Authentication, requires the TSF to ensure that all subjects attempting to perform TSF-mediated actions are identified and authenticated prior to authorizing these actions to be performed.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: |
FIA_UAU.5 Multiple Authentication Mechanisms |
FIA_X509_EXT.1, X.509 Certificate Validation, defines how the TSF must validate X.509 certificates that are presented to it.
FIA_X509_EXT.2, X.509 Certificate Authentication, requires the TSF to identify the functions for which it uses X.509 certificates for authentication
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: No other components.
Dependencies to:
FCS_COP.1 Cryptographic Operation
FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)
FPT_STM.1 Reliable Time Stamps
The following actions could be considered for the management functions in FMT:
Hierarchical to: No other components.
Dependencies to:
FIA_X509_EXT.1 X.509 Certificate Validation
FMT_CFG_EXT.1, Secure by Default Configuration, requires that default Administrator credentials be changed immediately after first use.
Hierarchical to: No other components.
Dependencies to:
FIA_UAU.1 Timing of Authentication
FMT_SMR.1 Security Roles
FPT_JTA_EXT.1, JTAG/Debug Port Access, requires that debug ports be accessible only to authorized Administrators.
FPT_JTA_EXT.2, JTAG/Debug Port Disablement, requires that debug ports be disabled.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
There are no management functions foreseen.
There are no audit events foreseen.
FPT_ROT_EXT.1, Platform Integrity Root, requires that the platform integrity be anchored in a root of trust.
FPT_ROT_EXT.2, Platform Integrity Extension, specifies how platform integrity is extended from the integrity root to other platform firmware.
FPT_ROT_EXT.3, Hardware component integrity, requires that the TOE support hardware supply chain integrity.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: |
FPT_ROT_EXT.1 Platform Integrity Root |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: |
FPT_ROT_EXT.1 Platform Integrity Root |
FPT_PPF_EXT.1, Protection of Platform Firmware and Critical Data, requires that the TSF prevent platform firmware from being modified outside of the update mechanisms defined in FPT_TUD_EXT.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FPT_RVR_EXT.1, Platform Firmware Recovery, defines mechanisms for recovering from a platform firmware integrity failure.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FPT_TUD_EXT.4 Secure Local Update Mechanism |
FPT_TUD_EXT.1, TOE Firmware Update, requires that the TSF support update of platform firmware.
FPT_TUD_EXT.2, Platform Firmware Authenticated Update Mechanism, specifies the requirements for authenticated update of platform firmware.
FPT_TUD_EXT.3, Platform Firmware Delayed-Authentication Update Mechanism, specifies the requirements for delayed-authentication update of platform firmware.
FPT_TUD_EXT.4, Secure Local Platform Firmware Update Mechanism, specifies the requirements for secure local update of platform firmware.
The following actions could be considered for the management functions in FMT:
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FPT_TUD_EXT.2 Platform Firmware Authenticated Update Mechanism FPT_TUD_EXT.3 Platform Firmware Delayed-Authentication Update Mechanism FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_COP.1 Cryptographic Operations |
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: |
| FPT_ROT_EXT.2 Platform Integrity Extension |
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FMT_CFG_EXT.1, Secure by Default Configuration, requires that default Administrator credentials be changed immediately after first use.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FIA_UAU.1 Timing of Authentication FMT_SMR.1 Security Roles |
FTP_ITC_EXT.1, Trusted Channel Communication, requires the TSF to implement one or more cryptographic protocols to secure connectivity between the TSF and various external entities.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
| Hierarchical to: | No other components. |
| Dependencies to: | No dependencies. |
FTP_ITE_EXT.1, Encrypted Data Communications, requires the TSF to encrypt data in the specified manner using key data that is provided to an external entity in the specified manner.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_COP.1 Cryptographic Operation |
FTP_ITP_EXT.1, Physically Protected Channel, requires the TSF to use a physically protected channel for transmission of data to an external entity.
There are no management functions foreseen.
There are no audit events foreseen.
FDP_ITC_EXT.1, Key/Credential Import, requires the TSF to implement one or more means for importing keys and credentials into the TOE, which are not addressed by the FDP_ITC component.
There are no management functions foreseen.
There are no audit events foreseen.
| Hierarchical to: | No other components. |
| Dependencies to: |
FCS_COP.1 Cryptographic Operation FCS_STG_EXT.1 Key Storage Encryption FTP_ITC_EXT.1 Trusted Channel Communications FTP_ITE_EXT.1 Encrypted Data Communications FTP_ITP_EXT.1 Physically Protected Channel |
FDP_TEE_EXT.1, Trusted Execution Environment for Tenant Software, requires the TSF to implement a trusted execution environment for the use of tenant software.
There are no management functions foreseen.
There are no audit events foreseen.
This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 3 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP provides evidence that these controls are present and have been evaluated.
. Table 16: Implicitly Satisfied Requirements| Requirement | Rationale for Satisfaction |
| FIA_UAU.1 – Timing of Authentication | FMT_CFG_EXT.1 has a dependency on FIA_UAU.1 because it cannot exist unless the TOE supports an authentication mechanism. |
| Factor | Same/Different | Guidance |
| Product Type | Different | Products in different product classes are not equivalent. Servers, EUDs, and IoT devices are not equivalent. |
| Product Vendors | Different | Products manufactured by different vendors are not equivalent. |
| PP-Specified Functionality | Same | If differences between products affect only non-PP-specified functionality, then the models are equivalent. |
| Different | If PP-specified security functionality is affected by the differences between products, then the products are not equivalent and must be tested separately. It is necessary to test only the functionality affected by the differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the products are fully tested separately, then there is no need to document the differences. |
| Factor | Same/Different/None | Guidance |
| Processor Vendors | Different | Functionality implemented through processors manufactured by different vendors is not equivalent. |
| Processor/Chipset Architecture | Different | Functionality implemented through processors with different processor and chipset architectures are not equivalent. |
| Firmware Versions | Same | Functionality implemented through equivalent processors by the same version of firmware is considered equivalent. |
| PP-Specified Functionality | Same | For PP-specified security functionality implemented through equivalent processors and different firmware versions, the platforms are equivalent with respect to the functionality if execution of the functionality follows the same code paths on both platforms. |
| PP-Specified Functionality | Different | For PP-specified security functionality implemented through equivalent processors and different firmware versions, the platforms are not equivalent with respect to the functionality if execution of the functionality follows different code paths on both platforms. |
| Acronym | Meaning |
|---|---|
| AES | Advanced Encryption Standard |
| AK | Asymmetric Key |
| ANSI | American National Standards Institute |
| API | Application Programming Interface |
| BAF | Biometric Authentication Factor |
| BMC | Baseboard Management Controller |
| Base-PP | Base Protection Profile |
| BMC | Baseboard Management Controller |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| CMAC | Cipher-based Message Authentication Code |
| CN | Common Names |
| cPP | Collaborative Protection Profile |
| CRL | Certificate Revocation List |
| CSP | Critical Security Parameters |
| CSfC | Commercial Solutions for Classified |
| CSP | Critical Security Parameters |
| DAR | Data-at-Rest |
| DH | Diffie-Hellman Key Exchange |
| DN | Distinguished Name |
| DRBG | Deterministic Random Bit Generator |
| DSS | Digital Signature Standard |
| DTLS | Datagram Transport Layer Security |
| ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| ECIES | Elliptic Curve Integrated Encryption Scheme |
| EP | Extended Package |
| EUD | End-User Device |
| FIPS | Federal Information Processing Standards |
| FP | Functional Package |
| FQDN | Fully Qualified Domain Name |
| GPCP | General-Purpose Computing Platform |
| HMAC | Hash-based Message Authentication Code |
| HTTPS | Hypertext Transfer Protocol Secure |
| IEC | International Electrotechnical Commission |
| IEEE | Institute of Electrical and Electronics Engineers |
| IoT | Internet of Things |
| IP | Internet Protocol |
| ISO | International Organization for Standardization |
| IT | Information Technology |
| ITSEF | Information Technology Security Evaluation Facility |
| IoT | Internet of Things |
| JTAG | Joint Test Action Group |
| KDF | Key-Derivation Function |
| KMAC | KECCAK Message Authentication Code |
| MAC | Message Authentication Code |
| MC | Management Controller |
| NIST | National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OE | Operational Environment |
| OEM | Original Equipment Manufacturer |
| OID | Object Identifier |
| OMTP | Open Mobile Terminal Platform |
| OS | Operating System |
| PBKDF | Password-based Key-Derivation Function |
| PKCS | Public Key Cryptography Standards |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
| RBG | Random Bit Generator |
| RFC | Request for Comment |
| RNG | Random Number Generator |
| RoT | Root of Trust |
| SA | Security Association |
| SAN | Subject Alternative Name |
| SAR | Security Assurance Requirement |
| SFR | Security Functional Requirement |
| SHA | Secure Hash Algorithm |
| SK | Symmetric Key |
| SPD | Security Policy Database |
| SSH | Secure Shell |
| ST | Security Target |
| SWID | Software Identification |
| TEE | Trusted Execution Environment |
| TLS | Transport Layer Security |
| TOE | Target of Evaluation |
| TSF | TOE Security Functionality |
| TSFI | TSF Interface |
| TSS | TOE Summary Specification |
| USB | Universal Serial Bus |
| VPN | Virtual Private Network |
| VS | Virtualization System |
| XCCDF | eXtensible Configuration Checklist Description Format |
| XOR | Exclusive Or |
| cPP | Collaborative Protection Profile |
| Identifier | Title |
|---|---|
| [CC] | Common Criteria for Information Technology Security Evaluation -
General Model
|
| [CEM] | Common Evaluation Methodology for Information Technology Security Evaluation -
Methodology
|
| [OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |